home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / pc / files / p_misc / netconf.arc / AARP.TXT < prev    next >
Text File  |  1988-12-10  |  16KB  |  322 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.                    Thoughts on the Issues of Address Resolution and
  7.                                        Routing
  8.                        in Amateur Packet Radio TCP/IP Networks
  9.  
  10.  
  11.                                  Bdale Garbee, N3EUA
  12.  
  13.  
  14.  
  15.                                        _A_B_S_T_R_A_C_T
  16.  
  17.                      The current KA9Q software  includes  a  technique
  18.                 for automatic address resolution, but does not include
  19.                 automatic routing features.   The  difference  between
  20.                 routing  and  address  resolution  is  explained,  and
  21.                 several concerns for on-air  automatic  routing  algo-
  22.                 rithm implementations are mentioned.
  23.  
  24.  
  25.  
  26.            _B_a_c_k_g_r_o_u_n_d:
  27.  
  28.            One of the major goals of those involved in the  TCP/IP  project
  29.            begun  by Phil Karn KA9Q has been to develop a network implemen-
  30.            tation that automatically handles routing.   By  this,  we  mean
  31.            that  it  should  not  be  necessary for an end user to have any
  32.            knowledge of the topology of the network he is using in order to
  33.            perform  normal  ``day-to-day''  network activities.  The user's
  34.            involvement should extend only to requests  of  the  form  ``get
  35.            file from host <n>'' or ``send mail to user <n> at host <m>''.
  36.  
  37.            Several groups are currently working on software that implements
  38.            one  or  another form of automatic routing.  The NET/ROM product
  39.            requires that the user only know the  nearest  NET/ROM  site  to
  40.            both the originating and destination stations in order to estab-
  41.            lish a circuit between the two.  The  TEXNet  system  reportedly
  42.            handles  traffic between its endnodes in a similarly transparent
  43.            fashion.  But in both of these cases, the  user  must  still  be
  44.            aware  of  some aspects of the network topology above and beyond
  45.            knowing the hostname of the destination site.
  46.  
  47.            What we have right now _i_s_n'_t _g_o_o_d _e_n_o_u_g_h!
  48.  
  49.            _A_R_P, _t_h_e _A_d_d_r_e_s_s _R_e_s_o_l_u_t_i_o_n _P_r_o_t_o_c_o_l:
  50.  
  51.            In his TCP/IP package, Phil Karn has included an  implementation
  52.            of  the  ARP  Address  Resolution Protocol, which was originally
  53.            created to allow for automatic mapping of  32-bit  IP  addresses
  54.            into  48-bit  Ethernet  addresses  on a local wired subnet.  ARP
  55.            works by having the originating station issue an ``ARP Request''
  56.            whenever  it  wishes to converse with a host whose IP address is
  57.            known, but whose ``physical address'' is unknown.  An  important
  58.  
  59.  
  60.                                    December 6, 1988
  61.  
  62.  
  63.  
  64.  
  65.  
  66.            thing  to remember about ARP is that it was designed for subnets
  67.            where all hosts can hear each other directly.
  68.  
  69.            In the Amateur Packet world, the physical address is  equivalent
  70.            to  the  destination station's callsign and optional sub-station
  71.            identifier, or SSID.  If and when the destination station  hears
  72.            the  broadcasted  request,  it knows the IP address and physical
  73.            address of the sending station by examining the contents of  the
  74.            request  packet,  and  it  responds  by sending an ``ARP Reply''
  75.            packet directly to the originating station.
  76.  
  77.            The value of ARP is that the only piece of information  about  a
  78.            station  that  you  need  to know ahead of time in order to make
  79.            contact with them is their IP  address,  as  long  as  they  are
  80.            within  RF  range.   ARP  performs  very well at the task it was
  81.            designed for, which is simple mapping of  logical  address  into
  82.            physical address.
  83.  
  84.            _T_h_e _S_t_a_t_e _o_f _R_o_u_t_i_n_g:
  85.  
  86.            There are two simple situations that demonstrate the limitations
  87.            of  ARP,  and  will serve to distinguish address resolution from
  88.            routing.  Let us consider the IP Switch, and the Digipeater.
  89.  
  90.            A digipeater is a device that receives a packet  that  has  been
  91.            source  routed  through  it,  and echoes that same packet on the
  92.            same or a different channel, changing the packet only by marking
  93.            it  as ``having been digipeated by this site''.  Our interest in
  94.            digipeaters  stems  only  from  their  current  popularity,  and
  95.            resulting  availability.   In  order to make use of a digipeater
  96.            with the KA9Q Internet software, both the source and destination
  97.            stations  need  to  explicitly provide the physical ``digipeater
  98.            string'' information to the NET.EXE package, as ARP  is  totally
  99.            unaware  of  the  existence  of  digipeaters.  This is not good.
  100.            Several extensions to ARP have been proposed, but a better solu-
  101.            tion  than extending ARP may be to manual routing of digipeaters
  102.            for IP, and rely on IP Switches  and/or  other  ``level  three''
  103.            network implementations to make the subnet appear to be contigu-
  104.            ous.
  105.  
  106.            An IP Switch in a certain sense performs the same function as  a
  107.            digipeater  from  the  end-user  viewpoint.  The Switch receives
  108.            packets that are destined for other hosts, and forwards them via
  109.            one of perhaps several channels.  For those familiar with Ether-
  110.            net or other wired networks running TCP/IP, an IP Switch in  the
  111.            Packet Radio environment differs from an IP Gateway primarily in
  112.            that a Switch may want to retransmit a packet on the same  chan-
  113.            nel it heard it on, while a Gateway would never want to do that.
  114.            The fundamental difference between a digipeater and a Switch  is
  115.            that  a  Switch  makes  routing  decisions,  while  a digipeater
  116.            depends on the end user to source-route a connection through it.
  117.  
  118.            Address resolution therefore  is  the  mapping  of  a  ``network
  119.            address'', such as an IP address in the TCP/IP environment, into
  120.            an actual physical station identifier, such as a  TNC  callsign.
  121.  
  122.  
  123.                                    December 6, 1988
  124.  
  125.  
  126.  
  127.  
  128.  
  129.            Routing  is the set of issues and algorithms that surround pass-
  130.            ing packets through intermediate stations.
  131.  
  132.            _T_h_o_u_g_h_t_s _A_b_o_u_t _W_h_a_t _W_e _N_e_e_d:
  133.  
  134.            Routing individual datagrams is currently  handled  by  manually
  135.            inserting entries into a station's ``route table'' that tell the
  136.            software to  route  all  packet  for  a  given  subrange  of  IP
  137.            addresses via a specified gateway, or switch.  This is already a
  138.            very powerful mechanism, in that a user can specify his  default
  139.            routing  to  be via his local switch, and then add special cases
  140.            to ``un-default'' local stations he can hit  directly,  and  the
  141.            end user problem is therefore greatly reduced.
  142.  
  143.            But the IP Switches currently run the same software.   The  only
  144.            way  to build a network is to manually create routing entries at
  145.            each switch.  We need to develop an algorithm for  automatically
  146.            determining  reasonable paths, that can automatically update the
  147.            routing tables at each Switch site.   There  are  two  different
  148.            philosophies  about  how  to  do this.  One is based on the idea
  149.            that the network should ``already know'' what to  do  with  each
  150.            packet  when it arrives at a given switch location, the other is
  151.            based on the idea that someone requesting a connection to a site
  152.            that is not known locally generates by their request the initia-
  153.            tive for the network to go figure out how to get there.
  154.  
  155.            The tradeoff at the highest level is simple.  The first  mechan-
  156.            ism  forces  the  network to continuously be passing information
  157.            about routes between switches, all of which is network overhead.
  158.            The  second  mechanism  generates a great deal of traffic on the
  159.            first request for a path segment that does not  currently  exist
  160.            in  the  routing  tables,  but  probably  has  a  lower overhead
  161.            overall.  It does, however, cause a  much  greater  ``turnaround
  162.            time'' delay for the user requesting an unusual route.  What the
  163.            best solution to this tradeoff between overhead  and  individual
  164.            user performance is has not in my opinion been sufficiently con-
  165.            sidered.
  166.  
  167.            A final thought for this paper is that we need  to  be  able  to
  168.            handle  mobile  stations,  not  just stations that are away from
  169.            their home switches, but stations that are actually  in  motion.
  170.            This  probably  cannot be done by schemes that dynamically reas-
  171.            sign IP addresses for the simple reason  that  a  station  might
  172.            have a connection in progress when it crosses a switch boundary.
  173.            Food for thought.
  174.  
  175.            _R_e_l_a_t_e_d _I_s_s_u_e_s:
  176.  
  177.            There are two other issues that need to be  considered.  One  is
  178.            the  mapping  of  mnemonic hostnames into IP addresses, both for
  179.            clients like FTP and Telnet, and for Mail  transfer.   Secondly,
  180.            there  is  a separate but similar routing problem that exists in
  181.            the mail handling portion of the network  software,  in  that  a
  182.            given  node  may have more than one mail transport system avail-
  183.            able to it (including perhaps things like  uucp  and  Fidomail),
  184.  
  185.  
  186.                                    December 6, 1988
  187.  
  188.  
  189.  
  190.  
  191.  
  192.            and  must make a ``routing decision'' as to which delivery agent
  193.            should be called to process a given message.
  194.  
  195.            The current means of handling the mapping of mnemonic  hostnames
  196.            into  IP  addresses  is  to maintain a file listing the possible
  197.            translations that are known to the  system,  and  requiring  the
  198.            user to specify the IP address directly when a host entry cannot
  199.            be matched.  A much better system would be to designate a  host-
  200.            name  server  in each local subnet, and have the client software
  201.            negotiate with the  name  server  to  map  a  hostname  into  an
  202.            address.   This reduces by far the number of locations that must
  203.            maintain a full hostname database.  Cacheing of some  number  of
  204.            most  recently or frequently used addresses on the local machine
  205.            should minimize the impact  of  name-serving  on  the  network's
  206.            overall performance.
  207.  
  208.            Mail routing is a fascinating topic, but one which deserves much
  209.            more  room  than  that  which is available here.  Suffice to say
  210.            that the problem  of  mapping  a  given  mail  message  into  an
  211.            appropriate  delivery agent on a given mail-handling host can be
  212.            as simple or as complicated  as  routing  packets  at  a  packet
  213.            switch.
  214.  
  215.            _W_r_o_n_g _T_h_i_n_g_s _W_e _C_o_u_l_d _D_o:
  216.  
  217.            With amazing regularity,  well-meaning  hams  have  suggested  a
  218.            variety  of  schemes for ``routing'' packets based on everything
  219.            from grid squares to zip codes, to telephone exchange  prefixes.
  220.            The  fundamental  problem with this is that _t_h_e_r_e _i_s _n_o _r_e_l_a_t_i_o_n
  221.            _b_e_t_w_e_e_n _a _h_o_s_t'_s _n_a_m_e _o_r _a_d_d_r_e_s_s _a_n_d _w_h_a_t _i_s _t_h_e  _b_e_s_t  _p_a_t_h  _t_o
  222.            _t_a_k_e  _t_o  _r_e_a_c_h  _t_h_a_t  _h_o_s_t.  A classic example is the satellite
  223.            ``wormhole'' between CA and MD, which often means  that  to  get
  224.            from the midwest to the east coast, the best path would be to go
  225.            west, _n_o_t _e_a_s_t, to the wormhole end, and tunnel across country.
  226.  
  227.            We need to design automatic routing mechanisms that do not  rely
  228.            on  host  names  or  network  addresses.   We  can use names and
  229.            addresses as hints, but cannot expect them to always work,  par-
  230.            ticularly  given  the  mobile nature of the modern ham!  Routing
  231.            depends on a network's topology, not the geography or  political
  232.            boundaries that it crosses.  Any routing mechanism that we adopt
  233.            _m_u_s_t handle mobile stations as well, which is virtually impossi-
  234.            ble when the routing mechanism is based on some fixed geographi-
  235.            cal reference system.
  236.  
  237.            Another interesting proposal has been to  not  assign  fixed  IP
  238.            addresses  to  individual  stations.  There are some schemes for
  239.            dynamically assigning addresses to small hosts in use  in  major
  240.            universities,  but  I  am  not yet convinced that this is a good
  241.            thing to do on packet, primarily because our  environment  poses
  242.            some  additional  complications  over those present in the wired
  243.            university environment.  The most obvious of which is the mobile
  244.            station, which might have a connection in progress as it crosses
  245.            an address allocation zone.  None of the existing schemes that I
  246.            am aware of allow for mobile stations.  We should, however, keep
  247.  
  248.  
  249.                                    December 6, 1988
  250.  
  251.  
  252.  
  253.  
  254.  
  255.            an eye on progress in this direction outside of  amateur  radio,
  256.            in case someone makes it work.
  257.  
  258.            _C_o_n_c_l_u_s_i_o_n:
  259.  
  260.            The purpose of this paper has been to document  some  goals  for
  261.            those  implementing  routing mechanisms for packet radio, and to
  262.            raise some specific concerns that should be understood and  con-
  263.            sidered.   Much work remains to be done.  Many of the ideas dis-
  264.            cussed here are under consideration by the group of people work-
  265.            ing  with  the  KA9Q  Internet software, and undoubtedly we will
  266.            eventually see an automatic  routing  implementation  either  as
  267.            part  of  the  package,  or  adopted from a third-party source's
  268.            level three implementation.
  269.  
  270.            _R_e_f_e_r_e_n_c_e_s:
  271.  
  272.            1.   Tanenbaum,  A.S.,  ``Computer  Networks'',   Prentice-Hall,
  273.                 1981.
  274.  
  275.            2.   RFC826, Address Resolution Protocol.
  276.  
  277.            3.   Beattie, J.G., ``Proposal:  Recommendation AX.121NA Number-
  278.                 ing  Plan For The Amateur Radio Network in North America'',
  279.                 _F_o_u_r_t_h _A_R_R_L _A_m_a_t_e_u_r _R_a_d_i_o _C_o_m_p_u_t_e_r  _N_e_t_w_o_r_k_i_n_g  _C_o_n_f_e_r_e_n_c_e,
  280.                 1984.
  281.  
  282.            4.   Beattie, J.G., ``Proposal:  Recommendation AX.121  Interna-
  283.                 tional  Numbering  Plan  For  The  Amateur Radio Network'',
  284.                 _F_i_f_t_h _A_R_R_L _A_m_a_t_e_u_r _R_a_d_i_o  _C_o_m_p_u_t_e_r  _N_e_t_w_o_r_k_i_n_g  _C_o_n_f_e_r_e_n_c_e,
  285.                 1986.
  286.  
  287.            5.   Fox, Terry, ``Amateur  Network  Addressing  and  Routing'',
  288.                 _F_i_f_t_h  _A_R_R_L  _A_m_a_t_e_u_r  _R_a_d_i_o _C_o_m_p_u_t_e_r _N_e_t_w_o_r_k_i_n_g _C_o_n_f_e_r_e_n_c_e,
  289.                 1986.
  290.  
  291.            6.   NET/ROM Beta-Test Preliminary Documentation, Software  2000
  292.                 Inc.
  293.  
  294.            7.   TEXNet Presentation at the 1987 TAPR Annual Meeting.
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.                                    December 6, 1988
  312.  
  313.  
  314. 
  315.